System and method for an extendable mobile communications device user interface

ABSTRACT

A system and method for an extendable software interface includes software architecture for use in a mobile device having a processor and a memory device. The software architecture includes a set of first-order controller software instructions configured to interface the application program with a first-order data model, and a first-order data object stored in the memory device in the form of the first-order data model. The first-order data object includes a second-order data object. A second-order set of controller software instructions configured to interact with the second-order data object is also included in the software architecture.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/887,758, filed on Sep. 22, 2010, which is a continuation of U.S.patent application Ser. No. 11/237,010, filed on Sep. 28, 2005, (nowU.S. Pat. No. 7,805,729), which is a continuation of U.S. patentapplication Ser. No. 09/897,207, filed on Jul. 2, 2001, (now U.S. Pat.No. 6,990,672), which claimed priority from U.S. Provisional ApplicationNo. 60/215,605, filed Jun. 30, 2000. These prior applications, includingtheir entire written descriptions and drawing figures, are herebyincorporated into the present application by reference.

BACKGROUND

1. Field of the Invention

This invention relates generally to a software interface for a mobiledevice. More particularly, the invention provides an extendable softwareinterface enabling forward compatibility in a mobile device, such thatnew applications may be easily integrated into the mobile device. Thisinvention is particularly well-suited for use in Personal DigitalAssistants, mobile communication devices, cellular phones, and wirelesstwo-way email communication devices (collectively referred to herein as“mobile devices”).

2. Description of the Related Art

Typical mobile device interfaces are constrained by resource limitationson the mobile device as compared to those of a desktop system. As aresult of these constraints, known mobile device interfaces aregenerally either hard-wired or hard-coded. In either case, the knownmobile device interfaces are immutable once the mobile device has beenmanufactured. For instance, in a hard-wired mobile device, physicalcomponents, such as push buttons and displays, are generally integratedinto a user interface by control logic wired into a printed circuitboard. Consequently, a hard-wired mobile device is not capable of beingupgraded to support new applications. In a hard-coded mobile device, aprogrammable device is typically used for the control logic, and theuser interface is generally controlled by the firmware and/or operatingsystem of the mobile device. New applications can generally be added toa hard-coded mobile device, but this process typically involvesreplacing or upgrading the interface software, which often involves arisk of breaking compatibility with legacy features of the mobiledevice. In addition, neither hard-wired nor hard-coded mobile devicestypically allow a user to seamlessly interface between an applicationprogram and data types associated with other application programs.

SUMMARY

A system and method for an extendable software interface includes asoftware architecture for use in a mobile device having a processor anda memory device. The software architecture comprises a plurality ofapplication programs stored in the memory device and executed by theprocessor, and at least one controller module for interfacing theplurality of application programs with a data model configured tointeract with a particular type of data object. Each controller moduleutilizes one or more generic interfaces with the plurality ofapplication programs, and also utilizes a specific interface with thedata model.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing a mobile device with an exemplaryextendable software interface;

FIG. 2 is a block diagram illustrating the interaction between fourexemplary controllers and four exemplary data models;

FIG. 3 is a block diagram illustrating that multiple controllers havinggeneric interfaces can each interact with the same application program;

FIG. 4 is a block diagram illustrating that controllers are singletonseach capable of interfacing with multiple data modules of the same type;

FIG. 5 is a block diagram illustrating exemplary second-ordercontrollers and second-order data models;

FIG. 6 is a block diagram showing an alternative embodiment in whichsecond-order objects are accessed with second-order controllers and afirst-order data model;

FIG. 7 illustrates an implementation of the extendable softwareinterface that adds functionality to an e-mail message application;

FIG. 8 illustrates an implementation of the extendable softwareinterface that adds third-party stock brokerage functions to the e-mailmessage application; and

FIG. 9 is a flow diagram showing an exemplary method for addingfunctionality to an application operating on a mobile device byutilizing the extendable software interface.

DETAILED DESCRIPTION

Referring now to the drawing figures, FIG. 1 is a block diagram showinga mobile device 10 with an exemplary extendable software interface. Themobile device comprises a processor 12 coupled to a system memory 14, aninput device 20, a display 22, and a transceiver 24. Within the systemmemory 16 is an operating system 26 that includes a virtual machine 28.The virtual machine 28 operates using two types of software modules,controllers 30 and data models 32, that interface with applicationprograms 34 through a plurality of generic interfaces 18.

Operationally, the software interface of the mobile device 10 isextended using the software modules 30 and 32, and the genericinterfaces 18. The software modules 30 and 32 are executed by thevirtual machine 28, which is preferably an object oriented run-timeenvironment such as Sun Micro System's J2ME (JAVA® 2 Micro Edition). Thesoftware modules 30 and 32 are preferably constructed using a JAVA®compiler capable of enforcing a software application interoperationarchitecture that takes on the form of a collection of compiled classesand objects along with an application programming interface (API).

Data models 32 are classes that represent the various types of datastored on the mobile device 10. The types of data may include, forexample, e-mail messages, address book entries, calendar items, tasks,and memos. In addition, next-generation mobile devices may store datasuch as SMS messages, phone call logs, voice mail indicators, WAPrequests, multiple e-mail sources, HTML content exchanges, specializedbanking services, financial services, field server and customer serviceofferings, or downloads from corporate databases.

The data models 32 are preferably stored on the mobile device 10 in theform of Java objects for execution in the J2ME run time environment.Each data model 32 is designed for a particular type of data object, andincludes specialized functions for retrieving information associatedwith the data type. For example, an e-mail message model may havespecialized functions for retrieving the subject of the e-mail objectand for retrieving the body of the e-mail object. A calendar entrymodel, on the other hand, may include specialized functions specific toa calendar entry object, such as a function capable of retrieving theduration of an appointment.

Each type of data model 32 has an associated controller 30 capable ofinteracting with the specific functions of the data model 32 type andrepresenting the data model 32 in a uniform way to the rest of thesoftware interface system. Operationally, the controllers 30 isolate thedata models 32 from the generic interfaces 18, and implement the genericinterfaces 18 such that each controller 30 can be easily hosted by anyapplication program 34 that supports the genetic interfaces 18. In thismanner, the controllers 30 present a common, standard interface to anyapplication 34; and each application that supports the genericinterfaces 18 is able to interact with any arbitrary controller 30. Forexample, an e-mail application using one or more of the genericinterfaces 18 can interface with an address book controller to retrievean e-mail address from an address book data model. Moreover, existingcontrollers 30 can be used to interface with any new applicationssupporting the generic interfaces 18. In this manner, a mobile deviceuser is able to install new applications without having to upgrade hisor her operating system 26 or interface software 28. The flexibilityprovided by the interoperability of the controllers 30 may also enablethe mobile device user to expand the functionality of his or her mobiledevice 10 by interacting with third party applications, such as bankingor other commercial services.

The interaction between an application program 34 and any arbitrarycontroller 30 is primarily made possible by generic interfaces 18 thatare implemented each controller 30. The generic interfaces 18 aregeneric in the sense that they are object-oriented as opposed to beingspecific to a certain type of data. Put another way, each genericinterface 18 is preferably programmed to perform a certain operationregardless of the data type. Operationally, each application 34 ispreferably programmed to query any controller 30 to determine if thecontroller 30 supports one or more generic interfaces 18 required toperform a given operation. If so, the application 34 then interacts withthe controller 30 and its associated data model 32 to complete theoperation. For instance, an application 34 may query a controller 30 todetermine whether it supports a generic interface 18 capable of paintingan object (such as the body of an e-mail message) onto a screen, and ifso, then interface with an controller 30 to display the object. In thismanner, the same type of generic interface 18 that is used by anapplication 34 to display the body of an e-mail message could also beused, for example, to display a clipping from a lengthy SMS message. Inanother example, the same generic interface 18 used to display thee-mail message may also be used to receive an e-mail address from ane-mail controller and interface with an address book application topaint the address into an address file. Preferably, new controllerscould also be implemented that support new generic interfaces.Therefore, new controllers can easily be designed to interface Withupgraded applications supporting new functions, and still be compatiblewith older applications as long as the new controller includes the oldergeneric interfaces.

Three exemplary generic interfaces that may be implemented by acontroller 30 are briefly described below. It should be understood,however, that these are just a few examples of the many types of genericinterfaces that could be used within the system shown in FIG. 1.

-   1. PaintProvider—The Paint Provider interface supports painting a    data model 32 into a given region of an application program 34. For    example, this generic interface 18 could be used to instruct a    controller to paint a data model into a list view. The PaintProvider    interface may be implemented as follows:

public interface PaintProvider {   void paint(Object model, Graphics g,int x, int y,   int Width, int height, Object context); }

-   2. FieldProvider TheFieldProvider interface enables a controller 30    to provide an application program 34 with a read-only or editable    field from a data model 32. For instance, the FieldProvider    interface may enable a data model 32 to be displayed in a list of    fields, such as in the edit screen of an email message. The    FieldProvider interface may be implemented as follows:

public interface FieldProvider {   Field getField(Object model, Objectcontext) throws    NoFieldException;   void grabDataFromField(Objectmodel, Field field); }

-   3. VerbProvider—The VerbProvider interface enables a controller 30    to supply an array of “verbs” when a user selects an object    associated with a data model 32. For instance, when a user positions    a cursor over an object (such as a portion of text) associated with    a particular data model, the VerbProvider interface may display a    list of menu selections specific to that data model. The    VerbProvider interface may be implemented as follows:

public interface VerbProvider { Verb [ ] getVerbs(Object model, Objectcontext); Verb [ ] getDefaultVerb(Object model, Object context); }

FIG. 2 is a block diagram 40 illustrating the interaction between fourexemplary controllers 42, 44, 46 and 48, and four exemplary data models52, 54, 56 and 58. The exemplary controllers shown in the diagram 40include an e-mail message controller 42, an SMS message controller 44,an address book card controller 46, and a calendar entry controller 48.Each exemplary controller 42, 44, 46, and 48 is unique to a data modeltype; respectively shown in the diagram 40 as an e-mail message 52, aSMS message 54, an address book card 56, and a calendar entry 58. Theuniqueness of the controllers and their corresponding data models isillustrated by the varying shapes at the interface between eachexemplary controller 42, 44, 46, and 48 and data model 52, 54, 56, and58. In addition, each exemplary controller 42, 44, 46, and 48 includesthree generic interfaces: Interface A 60, Interface B 62, and InterfaceC 64. Although every controller 42, 44, 46, and 48 is unique to a datamodel 52, 54, 56, and 58, the same generic interfaces 60, 62 and 64 areimplemented universally throughout the software interface. Therefore, asdiscussed above with reference to FIG. 1, each exemplary controller 42,44, 46, and 48 is able to interface with any application program thatsupports the generic interfaces 60, 62 and 64.

FIG. 3 is a block diagram 70 illustrating that multiple controllers 72,74, 76 and 78 having generic interfaces 80, 82, and 84 can each interactwith the same application program 86. For example, FIG. 3 shows ane-mail message controller 72, an SMS message controller 74, a voice mailindicator controller 76, and a third-party supplied controller 78. Eachcontroller 72, 74, 76 and 78 includes the same three generic interfaces80, 82 and 84, and thus all four controllers 72, 74, 76 and 78 are ableto interact with the same application 86. In this manner, the interfacesoftware 28 remains consistent regardless of the data type beingaccessed. In addition, FIG. 3 demonstrates that a third-party may easilydesign a new controller 78 that is compatible with the existing softwareinterface system by including the generic interfaces 80, 82 and 84supported by the application program 86 and other applications on thesystem.

FIG. 4 is a block diagram 90 illustrating that controllers 92, 94, and96 are singletons each capable of interfacing with multiple data modelsof the same type. As data entries or messages are received into thesystem, they are preferably entered into a persisted list of dataobjects that is included in, or assessable to, each application program34. The persisted list should preferably identify a data model for eachdata object in the list. Since the same type of data model may often beassociated with multiple data objects in the list, multiple instances ofvarious data model software modules could be executing in the system atthe same time. This is illustrated in FIG. 4 by the multiple instancesof the e-mail message data models 98 and 100, the SMS message datamodels 102 and 104, and the voice mail indicator data models 106 and108.

In a preferred embodiment, however, the persisted list should notidentify a controller 92, 94 or 96 for each data object. Rather, theappropriate controller 92, 94 or 96 is preferably identified as someaction is taken with a data model 98, 100, 102, 104, 106 or 108. When anapplication 34 needs to access a data model, the application 34preferably (1) queries the data model for the correct controller, (2)calls the controller, and then (3) passes in the data model as the firstparameter. In this manner, the controllers 92, 94 and 96 are statelessobjects such that only one instance of a controller 92, 94 or 96 iscapable of handling all of the data models of a certain type that areexecuting in the system. For example, in FIG. 4 one instance of ane-mail message controller 92 interfaces with both instances of thee-mail message data model 98 and 100.

FIG. 5 is a block diagram 200 illustrating exemplary second-ordercontrollers 210, 212 and 214 and second-order data models 218, 220 and222. The controllers and data models illustrated in FIGS. 2-3 areexamples of software modules designed to interface with first orderobjects, such as an e-mail message, an address book entry or a calendaritem. In a preferred embodiment, however, the extendable softwareinterface is also capable of interfacing with multiple objects within afirst-order object, referred to herein as second-order objects. Anexample of a second-order object is an address that appears within thebody of an e-mail message. In order to interface with a second-orderobject, the extendable software interface preferably utilizessecond-order controllers that operate within a first-order controller.For instance, in FIG. 5 four second-order controllers 210, 212 and 214are shown within an e-mail message controller 226. Each of thesecond-order controllers 210, 212 and 214 are preferably programmed toaccess a particular type of second-order object. FIG. 5 shows oneexemplary method by which a second-order controller may access asecond-order object. In this embodiment, a second-order data model 218,220 or 222 is created for each type of second-order object. Thesecond-order data models 218, 220 and 222 preferably operate within afirst-order data model 228. In this manner, each second-order data model218, 220 or 222 is programmed to access a particular type of informationwithin a data type, thus enabling a second-order object to bemanipulated by an application program 34 through the second-ordercontrollers 210, 212 and 214. Examples illustrating the manipulation ofsecond-order objects are detailed below with reference to FIGS. 7 and 8.

FIG. 6 is a block diagram showing an alternative embodiment 300 in whichsecond-order objects are accessed with second-order controllers 302, 304and 306 and a first-order data model 310. In this embodiment, thefirst-order data object is grouped by the virtual machine 28 in such away that second-order data objects can be identified from within thefirst-order data model 310. This may be accomplished, for example, bygrouping a first order data object that includes multiple second-orderdata objects such that they appear to the system as essentially oneimmutable object. When the group is accessed by the virtual machine 28,however, each of the sub-pieces (second-order objects) of the group canbe independently accessed. The second-order controllers 302, 304 and 306are then programmed to identify the second-order data objects fromwithin the data object grouping. In this manner, memory space on thesystem can be better utilized by eliminating the need for second-orderdata models.

FIG. 7 illustrates an implementation of the extendable softwareinterface that adds functionality to an e-mail message application. Inthe embodiment shown in FIG. 7, any e-mail addresses that appear in anyportion of an e-mail message 400 are action-linked. This may beaccomplished, for example, by designing an e-mail message controllercapable of (1) recognizing e-mail addresses as second-order objects, and(2) delegating the interface between the e-mail message application andthe e-mail address to an object-specific, second-order e-mail addresscontroller operating within the e-mail controller. The e-mail addresscontroller should preferably be capable of retrieving e-mail addresses410 from a first-order e-mail message model. Alternatively, specializedsecond-order e-mail address models may be constructed to operate withinthe e-mail message model and interact with the e-mail addresscontroller. In either case, by defining e-mail addresses 410 assecond-order objects, and designing interface software modules capableof retrieving the addresses 410 from within any portion of an e-mailmessage 400, an existing e-mail application is extended such that it canperform previously unavailable operations.

For instance, with reference to FIG. 7, when a mobile device userpositions a cursor in the vicinity of the e-mail address“ulf@bigcompany.com” 410, the e-mail message controller preferablyrecognizes that the address 410 is a second-order object and calls thespecialized second-order e-mail address controller. Through one of thegeneric interfaces, the e-mail address controller then preferablypresents a list of functions 412 on a display of the device that can beperformed on the e-mail address 410. In addition, the function list 412may preferably include operations involving other applications. Forexample, the function “Add Ulf to address book” may require the e-mailaddress controller to interface with an address book application. Thisseamless operation is possible because the generic interfaces enable thee-mail address controller to interface with any application within thesystem.

FIG. 8 illustrates an implementation of the extendable softwareinterface that adds third-party stock brokerage functions 500 to thee-mail message application. In this example, an e-mail message 510 sentfrom a stock broker includes action-linked stock quotations 512. Inorder to implement this example, the mobile device manufacturer, orpreferably the third party, may design an e-mail message controllerupgrade that adds second-order controllers that are specific to dataobjects typically found in an e-mail from a stock broker. With referenceto the illustration, when a user positions a cursor in the vicinity of astock quote or ticker symbol 512 in the e-mail message 510, the upgradede-mail controller preferably (1) recognizes the quote or symbol 512 as asecond-order object and (2) calls the object-specific second-ordercontroller. The second-order controller then preferably presents a listof functions 500 to the e-mail message application that are capable ofbeing performed on the object 512. In this example, the availablefunctions are “SELL,” BUY,” “Request more info,” and “Cancel.” lf, forexample, the user selects the “SELL” function from the list 500, thenthe second-order controller may be programmed to (1) instruct the e-mailapplication to create a new e-mail message, (2) paint the address“stocks@tdbank.com” into the receiver line (the “To:” line) of the newmessage, (3) paint the address “MGeek@rim.net” into the sender line (the“From:” line) of the new message, and (4) paint the text “SELL” alongwith the second-order object “ALCN. TO 12.33-122.21” into the bodyportion of the new message. Significantly, none of these steps requirean upgrade to the e-mail message application. Rather, the extendablesoftware interface preferably enables additional functionality to beadded to an existing application with only a simple upgrade to theapplication's controller.

FIG. 9 is a flow diagram showing an exemplary method 600 for addingfunctionality to an application operating on a mobile device byutilizing the extendable software interface. In step 610, one or moresecond-order objects are defined within the first-order data modelassociated with the application. For instance, in an e-mail message datamodel, second-order objects may be defined as described above withreference to FIGS. 7 and 8. It should be understood, however, that thismethod 600 is not limited to an e-mail messaging application, but may beutilized with any application operating on a mobile device. In step 620,the application data model containing the second-order objects isdisplayed by the application. As discussed above with reference to FIG.1, the data model is preferably accessed by the application throughgeneric interfaces and a first-order controller. Once the data isdisplayed, a mobile device user may preferably select a second-orderobject by positioning a cursor on, or in the vicinity of, thesecond-order object (step 630). Alternatively, the second-order objectmay be selected by any other means available on the mobile device, suchas highlighting the object or touching the object with a stylus. When asecond-order object is selected by the user, the first-order controllerpreferably (1) recognizes the object as a second-order object, and (2)calls a second-order controller that is specifically designed to accessthe second-order object (step 640).

In step 650, the second-order controller preferably provides a list offunctions that may be performed on the second-order object. Once afunction associated with a second-order object has been selected by themobile device user (step 660), the second-order controller preferablyestablishes whether the function (1) relates to the current application,or (2) requires access to another application installed on the mobiledevice (step 670). For instance, if an address is selected as asecond-order object within an e-mail message, then the user may be giventhe option to (1) insert the address into the “To:” line of a newmessage, or (2) insert the address into an address book. If the userchooses to compose a new message using the selected address in the “To:”line, then the second-order (address) controller preferably knows thatthe selected operation relates to the e-mail messaging application thatis already executing. Then, the first and second-order controllers mayinterface with the currently executing application to perform theselected function (step 700). If, however, the user chooses to insertthe object into an address book file, then the e-mail message controllerand second-order address controller need access to an address bookapplication before the function can be completed. Therefore, whenanother application installed on the mobile device is required toperform the selected function, the new application is preferablylaunched by either the first or second-order controller (step 680).Then, because the first and second-order applications utilize genericinterfaces, both can interface with the new application to perform theselected function (steps 690 and 700).

The embodiments described herein are examples of structures, systems ormethods having elements corresponding to the elements of the inventionrecited in the claims. This written description may enable those skilledin the art to make and use embodiments having alternative elements thatlikewise correspond to the elements of the invention recited in theclaims. The intended scope of the invention thus includes otherstructures, systems or methods that do not differ from the literallanguage of the claims, and further includes other structures, systemsor methods with insubstantial differences from the literal language ofthe claims.

What is claimed:
 1. A method of operating a mobile device having adisplay, comprising: receiving at the mobile device an electronic ashort message service (SMS) message having a body, with an e-mailaddress within the body; displaying on the display at least a portion ofthe electronic SMS message including the e-mail address, wherein theportion of the SMS message is displayed in a first application operatingon the mobile device; and determining, by a message controller at themobile device, that the SMS message includes the e-mail address, whereinthe message controller is associated with an SMS data model, and the SMSdata model includes a retrieving function for retrieving the e-mailaddress from the SMS message; after determining that the SMS messageincludes the e-mail address, determining that a cursor is effected nearthe displayed e-mail address; in response to a selection of thedisplayed e-mail address, determining that the cursor is effected nearthe displayed e-mail address, activating, by the message controller, ane-mail address controller, wherein the e-mail address controller isdifferent than the message controller, the e-mail address controller isassociated with an e-mail address data model, wherein the e-mail addressdata model is associated with at least two functions to be performed onthe e-mail address, and the e-mail address controller is configured todisplay the at least two functions; displaying, by the e-mail addresscontroller at the mobile device, on the display an a first interface forselecting one of including the at least adding the e-mail address to anaddress book and creating an e-mail message addressed to the e-mailaddress two functions to be performed on the e-mail address, wherein theat least two functions include a first function executed by a secondapplication and a second function executed by a third applicationdifferent than the first and second applications; receiving, from thefirst interface, a selection of the first function executed by thesecond application; launching, by the e-mail address controller, thesecond application; retrieving, by the message controller using the SMSdata model, the e-mail address from the SMS message; and providing, bythe message controller, the retrieved e-mail address to the secondapplication.
 2. The method of claim 1, wherein the electronic message isan e-mail message.
 3. The method of claim 1, wherein the electronicmessage is an SMS message.
 4. The method of claim 1, wherein thereceiving at the mobile device the selection of the e-mail addresscomprises receiving a cursor positioning over the e-mail address.
 5. Themethod of claim 1, further comprising receiving selection of one of theat least adding the e-mail address to the address book and creating thee-mail message addressed to the e-mail address.
 6. The method of claim 51, further comprising: after launching an the second applicationassociated with the selection; and displaying a second interfacedifferent than the first interface.
 7. The method of claim 1, whereinthe first interface comprises a menu list.
 8. A mobile communicationdevice, comprising: a display; an input device; and a processor,connected to the display and the input device, and configured to:receive an electronic a short message service (SMS) message having abody, with an e-mail address within the body, display on the display atleast a portion of the electronic SMS message including the e-mailaddress, wherein the portion of the SMS message is displayed in a firstapplication operating on the mobile communication device, and determine,by a message controller at the mobile communication device, that the SMSmessage includes the e-mail address, wherein the message controller isassociated with an SMS data model, and the SMS data model includes aretrieving function for retrieving the e-mail address from the SMSmessage; after determining that the SMS message includes the e-mailaddress, determine that a cursor is effected near the displayed e-mailaddress; in response to a selection of the displayed e-mail address atthe input device determining that the cursor is near the displayede-mail address, activate, by the message controller, an e-mail addresscontroller, wherein the e-mail address controller is different than themessage controller, the e-mail address controller is associated with ane-mail address data model, wherein the e-mail address data model isassociated with at least two functions to be performed on the e-mailaddress, and the e-mail address controller is configured to display theat least two functions; display, by the e-mail address controller at themobile communication device, on the display an a first interface forselecting from including the at least two functions that can beperformed with the e-mail address, the at least two functions includingadding the e-mail address to an address book and creating an e-mailmessage addressed to the e-mail address to be performed on the e-mailaddress, wherein the at least two functions include a first functionexecuted by a second application and a second function executed by athird application different than the first and second applications;receive, from the first interface, a selection of the first functionexecuted by the second application; launch, by the e-mail addresscontroller, the second application; retrieve, by the message controllerusing the SMS data model, the e-mail address from the SMS message; andprovide, by the message controller, the retrieved e-mail address to thesecond application.
 9. The mobile communication device of claim 8,wherein the electronic message is an e-mail message.
 10. The mobilecommunication device of claim 8, wherein the electronic message is anSMS message.
 11. The mobile communication device of claim 8, wherein theat least two functions comprise an operation involving an applicationother than a message application.
 12. The mobile communication device ofclaim 8, wherein the at least two functions comprise an operationinvolving an address book application.
 13. The mobile communicationdevice of claim 8, wherein the receiving the selection of the displayede-mail address comprises receiving a cursor positioning over the e-mailaddress.
 14. The mobile communication device of claim 8, furthercomprising the processor configured to receive selection of one of theat least two functions.
 15. The mobile communication device of claim 14,further comprising the processor configured to launch an applicationassociated with the selected function.
 16. The method mobilecommunication device of claim 8, wherein the first interface comprises amenu list.
 17. A method of providing functionality on a mobile devicehaving a display, comprising: receiving at the mobile device an e-mailmessage with an e-mail address within a body of the e-mail message;displaying on the display at least a portion of the e-mail messageincluding the e-mail address; in response to a selection of thedisplayed e-mail address, displaying on the display a list of at leasttwo functions that can be performed with the e-mail address, the atleast two functions including adding the e-mail address to an addressbook on the mobile device and creating an e-mail message addressed tothe e-mail address; and receiving a selection of at least one of the atleast two functions, and then performing the selected function.
 18. Amobile communication device, comprising: a display; a transceiver; and aprocessor connected with the display and the transceiver, the processorconfigured for: receiving with the transceiver an e-mail message havingan e-mail address within a body of the e-mail message; displaying on thedisplay at least a portion of the e-mail message including the e-mailaddress; in response to a selection of the displayed e-mail address,displaying on the display a list of at least two functions that can beperformed with the e-mail address, the at least two functions includingadding the e-mail address to an address book on the mobile device andcreating an e-mail message addressed to the e-mail address; andreceiving a selection of at least one of the at least two functions, andthen performing the selected function.
 19. A non-transitory computerreadable medium storing instructions to cause a processor to performoperations comprising: receiving, at a mobile device, a short messageservice (SMS) message having a body, with an e-mail address within thebody; displaying at least a portion of the SMS message including thee-mail address, wherein the portion of the SMS message is displayed in afirst application; determining, by a message controller at the mobiledevice, that the SMS message includes the e-mail address, wherein themessage controller is associated with an SMS data model, and the SMSdata model includes a retrieving function for retrieving the e-mailaddress from the SMS message; after determining that the SMS messageincludes the e-mail address, determining that a cursor is effected nearthe displayed e-mail address; and in response to determining that thecursor is effected near the displayed e-mail address, activating, by themessage controller, an e-mail address controller, wherein the e-mailaddress controller is different than the message controller, the e-mailaddress controller is associated with an e-mail address data model,wherein the e-mail address data model is associated with at least twofunctions to be performed on the e-mail address, and the e-mail addresscontroller is configured to display the at least two functions;displaying, by the e-mail address controller at the mobile device, aninterface including the at least two functions to be performed on thee-mail address, wherein the at least two functions include a firstfunction executed by a second application and a second function executedby a third application different than the first and second applications;receiving, from the interface, a selection of the first functionexecuted by the second application; launching, by the e-mail addresscontroller, the second application; retrieving, by the messagecontroller using the SMS data model, the e-mail address from the SMSmessage; and providing, by the message controller, the retrieved e-mailaddress to the second application.
 20. The computer readable medium ofclaim 19, wherein the interface comprises a menu list.